In order to overcome the problem of interoperability between different object-oriented programming (OOP) languages, systems and methods have been suggested, which provide for bridges between the incompatible OOP languages. In operation, a bridge includes a map that translates expressions from one protocol to a different protocol. Hence, conceptually, the bridge resides at the boundary of each different protocol (e.g., at the boundary of two systems having different protocols). Thus, when a first-protocol expression is generated, the bridge translates the first-protocol expression into a second-protocol expression. Similarly, when a second-protocol expression is generated, the bridge translates the second-protocol expression into a first-protocol expression. In this regard, a mapping of the expression takes place from one protocol to another for each expression that crosses the boundary between two different protocols.
As one may guess, in order to maintain this type of interoperability, the system must continually maintain the bridge between two protocols. Otherwise, in the absence of the bridge, interoperability is destroyed. Also, since the bridge is only as good as the map that translates between the differing protocols, the functionality of the system is limited by the protocol having less functionality (i.e., the “weaker” protocol).
As an alternative to translating expressions at a bridge, an end user may re-write one OOP client-side to become the another OOP client-side. However, this type of re-writing becomes tedious and cumbersome because each application would be re-written for each non-native platform with which interoperability is sought.
Given these inefficiencies associated with translating expressions from one protocol to another protocol using a bridge, a need exists in the industry for greater efficiency in providing interoperability between incompatible protocols.